1. Field of the Invention
The present invention relates to an isochronous packet transfer method for transferring a packet for which the transfer band has been previously secured, on a communications network which uses a bus conforming to the specifications of IEEE (Institute of Electrical and Electronic Engineers) standard 1394 or USB (Universal Serial Bus). Furthermore, the present invention relates to a recording medium on which is stored an isochronous packet transfer control program serving as a means for executing the isochronous packet transfer method, a bridge, and a packet transfer control LSI (Large Scale Integrated Circuit).
This application is based on Japanese Patent Application No. Hei 11-271388, the contents of which are incorporated herein by reference.
2. Description of the Related Art
Recently, as a high performance serial bus standard having high speed transmission capability of for example 100 megabit per second (S100), 200 megabit per second (S200), or 400 megabit per second (S400), attention is being given to IEEE 1394 standard (xe2x80x9cIEEE-Std. 1394-1995, IEEE Standard for a High Performance Serial Busxe2x80x9d, abbreviated hereunder to xe2x80x9c1394 standardxe2x80x9d). In the 1394 standard, in order to transfer data in a real time system such as with images or voice where there is a problem if there is an interruption during playback, an xe2x80x9cisochronous transfer modexe2x80x9d for securing the packet transfer band is stipulated. This isochronous transfer mode is realized by a concept for a xe2x80x9ccyclexe2x80x9d nominally having a frequency of 8 kilohertz (a 125 microsecond period), and introducing a procedure for previously acquiring a time where packet transfer is possible for each cycle. Hereunder, a packet which is transferred by the isochronous transfer mode is referred to as an xe2x80x9cisochronous packetxe2x80x9d.
In order to understand the problems with the conventional technology, since knowledge of the 1394 standard is necessary, this will be described below in somewhat lengthy detail. At first is an explanation with reference to FIG. 17 of a specific method which is prescribed by 1394 standard in order to supervise a cycle. Of a number of 1394 standard nodes (referred to hereunder simply as a xe2x80x9cnodesxe2x80x9d) connected to a bus, a node referred to as a cycle master is defined. Then the respective nodes connected to a bus detect a packet referred to as a xe2x80x9ccycle start packetxe2x80x9d multicast from the cycle master, to thereby recognize cycle start. Furthermore, both the nodes and the cycle master for sending and receiving the isochronous packet are installed in a CYCLE_TIME register for storing time information. The cycle master uses this CYCLE_TIME register to keep the transmission period for the cycle start packet constant.
Here, FIG. 18 shows the format of the CYCLE_TIME register specified by 1394 standard. As shown in the figure, the CYCLE_TIME register is a 32 bit width register, with the 7 bits from the most significant bit referred to as a second_count field, then the next 13 bits referred to as a cycle_count field, and the 12 bits to the least significant bit referred to as a cycle_offset field. Of these, the cycle_offset field is a counter of 3072 (decimal number) scale which counts up with a clock of a nominal value of 24.576 megahertz, and after counting to xe2x80x9c3071xe2x80x9d (decimal number), returns to xe2x80x9c0xe2x80x9d. That is to say, with the count value of this counter, the value returns to xe2x80x9c0xe2x80x9d for each 125 microseconds, being the period of the cycle. Hereunder, provided there is no particular mention, all of the numerical values are expressed in decimals.
Next, the cycle_count field is an 8000-scale counter for counting the number of cycles. At a timing where the cycle_offset field returns to xe2x80x9c0xe2x80x9d (each 125 microseconds), the count value thereof counts up by xe2x80x9c1xe2x80x9d. That is to say, the count value of this counter counts to xe2x80x9c7999xe2x80x9d and returns to xe2x80x9c0xe2x80x9d every 1 second. Next, the second_count field is a 128 scale counter for counting xe2x80x9csecondsxe2x80x9d, and counts up by xe2x80x9c1xe2x80x9d at a timing where the cycle_count field returns to xe2x80x9c0xe2x80x9d. This counter value returns to xe2x80x9c0xe2x80x9d after counting to xe2x80x9c127xe2x80x9d.
Next, the format of the cycle start packet is shown in FIG. 19. In FIG. 19, a node ID (identifier) of the cycle master is contained in the source_ID field which indicates the packet transmission node. Respective unique node IDs are given to the respective nodes connected to the bus. Then, in the destination_ID field showing the packet reception node is stored xe2x80x9cFFFFxe2x80x9d (hexadecimal) showing multicast for all of the nodes. Next, an xe2x80x9c8xe2x80x9d showing that there is a cycle start packet, is stored in the t-code (transaction code) field showing the classification of the packet. Then stored in the cycle_time_data field is stored the value of the CYCLE_TIME register which is held by the cycle master when this cycle start packet is transmitted. Fields other than the above have no direct relation to this discussion and hence description thereof is omitted.
The nodes which do not become cycle masters receive the cycle start packet, and the values of the CYCLE_TIME register held by these nodes are overwritten by the values of the cycle_time_data field within the cycle start packet. By so doing, the value of the CYCLE_TIME register which all of the nodes connected to the bus hold, is synchronized with the value of the CYCLE_TIME register which the cycle master holds.
Now, as shown in FIG. 17, when the cycle start packet is transferred, the node for which the band has been previously acquired, starts transmitting the isochronous packet. Then, after a period where there is no data transfer, referred to as an xe2x80x9cisochronous gapxe2x80x9d has elapsed, bus arbitration is carried out, and transfer of the packet is performed in order from the node which has acquired the packet transmission right. By repeating these steps, transfer of all of the isochronous packets for which the band has been acquired is completed. By so doing, even if the period of the gap corresponding to the isochronous gap has elapsed, transmission of the isochronous packet by any of the nodes ceases.
Then, even if a period longer than the isochronous gap, referred to as a xe2x80x9csub-action gapxe2x80x9d has elapsed, and no isochronous packets are detected, this becomes a period for transferring a best effort type packet, referred to as asynchronous packet. The transfer period for the asynchronous packet continues until a cycle start packet showing start of the next cycle is detected. In the above manner, the first half of the respective cycles is assigned to the transfer period for the band secured isochronous packet, and the remaining latter half is assigned to a best effort type asynchronous packet transfer period. Here the band which can be used as a transfer period for the isochronous packet is controlled to a maximum of 80% with respect to the total (one cycle). In this way, a condition where the asynchronous packet cannot be transferred at all is avoided.
Cycle master attempts the transmission of a cycle start packet at a timing which the cycle_count field of the CYCLE_TIME register increments. However, the cycle start packet also is a type of asynchronous packet of the best effort type. That is, in addition to the timing which depends on the aforementioned CYCLE_TIME register, if the packet transmission right has not been acquired by performing arbitration of the bus after the sub-action gap is detected, then the cycle start packet cannot be transmitted. Consequently, if the packet being transferred is not on the bus, then the cycle start packet can be immediately transmitted at the timing which is incremented by the cycle_count field. On the other hand, in the situation such as the case where the packet being transferred is on the bus, the cycle start packet cannot be transmitted until after transmission of this packet has been completed.
The maximum value of the delay at the time of sending the cycle start packet depends on the allowable maximum packet size of the asynchronous packet. With the 1394 standard, the maximum data field length for the asynchronous packet for respective transmission speeds of S100, S200 and S400 is prescribed as 512 bytes, 1024 bytes and 2048 bytes respectively. Consequently, when processing time for attaching a header or CRC (Cyclic Redundancy Check) field to the data field is also taken into account, the time required for packet transfer is estimated to be approximately 45 microseconds. As will be understood from the above explanation, a cycle frequency of the nominal value of 8 kilohertz controlled by the cycle start packet, essentially has a jitter corresponding to the traffic on the bus. Here, in the case where the cycle start packet is sent later than the original transmission timing, the timing information which also includes this delay, is stored in the cycle_time_data field of the cycle start packet. Furthermore, the timing information stored in the CYCLE_TIME register is updated without depending on the transmission timing of the cycle start packet.
On the other hand, in the 1394 standard, an IEEE 1394 bridge (referred to hereunder simply as a bridge) for performing packet transfer between different buses with a plurality of 1394 standard buses (hereunder referred to as xe2x80x9c1394 busesxe2x80x9d) connected to each other is being studied, and standardization work is being undertaken by a P1394.1 Committee of the IEEE. Large scale and high efficiency of a network using the 1394 standard can be achieved using this bridge. Hereunder, is a description of the basic construction of the bridge, with reference to FIG. 20. The bridge is basically constructed from portals and a switching fabric. That is to say, the portals are the part where the bridge connects to the 1394 bus, and the portals themselves also operate as nodes. Moreover, the switching fabric is a packet switchboard for performing packet transfer between the portals inside the bridge.
In FIG. 20, the example is shown where the bridge 10 is constructed with three portals 20-22 and incorporates a switching fabric 30 which connects these together. However provided the number of portals incorporated in one bridge is more than one, then any number is possible. The portals 20-22 are respectively connected to buses 40-42 being 1394 buses, so that packet transfer is possible between these buses. Nodes 50-52 are respectively connected to these buses 40-42. Here the example is given for the case where a packet is transferred from the node 50 connected to the bus 40, to the node 51 connected to the bus 41 via the bridge 10, and an outline of the bridge operation is described.
At first, the portal 20 receives a packet which the node 50 has transmitted via the bus 40. Then, the received packet is examined to determine if the received packet is one for transferring to buses other than the bus 40. The method for examining this has been variously discussed by the P1394.1 Committee, and here the details are not addressed. Then, in the case where the portal 20 judges that the received packet is one for transferring to other buses, this packet is output to the switching fabric 30. The switching fabric 30 then outputs the input packet to a portal connected to the bus to which the packet is to be transferred. According to this example, the packet is output to the portal 21 connected to the bus 41. As a result, the portal 21 transfers the packet input from the switching fabric 30 to the bus 41, and the node 51 receives the packet via the bus 41, and packet transfer from the node 50 to the node 51 is thus completed.
In the above manner, the portal appropriately performs the operation of transferring the packets from the bus corresponding to its own, to the switching fabric 30, and the operation of transferring the packets from the switching fabric 30 to the target bus, to thereby perform transfer of the packets between the buses. Here, in a subsequent explanation, the former operation performed by the portal is referred to as an xe2x80x9cinput portal operationxe2x80x9d, while the latter operation is referred to as an xe2x80x9coutput portal operation.xe2x80x9d Furthermore, the portals fulfilling a role similar to that of the above mentioned portal 20 and portal 21 are respectively referred to as xe2x80x9cinput portalsxe2x80x9d and xe2x80x9coutput portalsxe2x80x9d.
Next, in the case where isochronous packet transfer is performed between different buses using the above-mentioned bridge, the transfer intervals between packets on the input portal side must also be maintained on the bus on the output portal side. The reason for this is so that traffic contravening the band of the bus which has been previously acquired for the isochronous packet transfer, is not sent to a bus. For example, in the case where a packet which has been input one packet at a time for each cycle, from the bus on the input portal side is transferred to another bus, then with the bus on the output portal side also, the packet must be transferred at a rate of one packet for each cycle. Nevertheless, if in a particular cycle a packet is not transmitted to the bus on the output portal side, and in the succeeding cycle two packets are transmitted, then in this following cycle, twice the traffic of the acquired band is momentarily sent.
Furthermore, in the 1394 standard, arbitration, gap, and cycle frequency jitter is present as mentioned above. In addition to the presence of these, in order to satisfy an above-described demand with the bridge 10, it is necessary to send the aforementioned isochronous packet to the bus on the output portal side, after applying a fixed delay of several cycles to the isochronous packet to be transferred. Here, the above-mentioned fixed delay which the bridge gives to the isochronous packet is referred to by the P1394.1 Committee as xe2x80x9cisochronous delay.xe2x80x9d Hereunder, is a detailed description of the requirements for this isochronous delay.
At first is a description of arbitration and fixed delay attributable to the gap, with reference to FIG. 21A and FIG. 21B. In these figures is shown in the traffic of the bus on the input portal side and the bus on the output portal side, together with a comparison for the case where cycle delay is not applied (FIG. 21A) and the case where a delay of one cycle is applied (FIG. 21B). Here in the same figures, for convenience the isochronous packets are represented by symbols xe2x80x9cAxe2x80x9d-xe2x80x9cExe2x80x9d, however actually each individual isochronous packet is identified according to the value of the channel number stored in the channel field in the header of the isochronous packet.
At the input portal side bus, three types of isochronous packets, A, B and C are transferred. Of these packets, packet A and packet B are regularly transferred, while packet C is only transferred in cycle C2. Furthermore, of the packets A, B and C, only the packet B is transferred between the buses towards the output portal side bus. On the other hand, with the isochronous packets transferred by the output portal side bus, in addition to packet B there is packet D and packet E. Furthermore, the node transmitting packet C, in the process of arbitration, can acquire the bus before the nodes transmitting packet A or packet B. Here, the portions in the figure shown in half-tone dot mesh are periods (hereunder referred to as xe2x80x9cisochronous periodsxe2x80x9d) where the isochronous packets are transferred in the respective cycles. The half-tone dot mesh is added to include as far as the sub-action gap showing the completion of the isochronous period.
Against the traffic of the input portal side bus as described above, the traffic of the output portal side bus for the case where a cycle delay is not given by the bridge is shown in FIG. 21A. As shown in this figure, the packet B is transferred from the input portal to the transmit buffer of the output portal, and is temporarily stored in the buffer. Then after the output portal acquires the bus by arbitration, the packet is transmitted to the output portal side bus. In this case, in cycle C1, the inter-bus transfer of the packet B is successfully performed. Here, the transmit buffer of the output portal is realized by a FIFO (first-in-first-out) memory or the like. This FIFO memory is installed on the link layer LSI for realizing a link layer in a layer construction of 1394 standard.
On the other hand, in cycle C2, the packet B is sent to the latter half of the isochronous period as the result of arbitration in the input portal side bus. Therefore, at the output portal side bus, the packet cannot be transmitted within the range of the upper limit of the isochronous period. That is to say, with the example in the figure, after packet E has been transferred, the isochronous gap elapses, and after for a while, the packet B is transferred. Therefore, the time of the sub-action gap at the end of the isochronous period cannot be sufficiently maintained. Consequently, although the transmission of the packet B to the output portal side bus is possible, this becomes a packet which contravenes the 1394 standard.
Furthermore, in cycle C3, there is no transmission of packet D and packet E with respect to the output portal side bus, as with cycle C1 and cycle C2. Therefore, in the timing where the packet B is transferred from the input portal side bus, at the output portal side bus, the sub-action gap is detected and there is a shift to the asynchronous period. Therefore, at cycle C3, packet B cannot be transmitted, and at cycle C3, a packet miss is generated. Here, packet B is transmitted in the cycle after cycle C3.
In the above manner, when a cycle delay is not given by the bridge, the problem arises in that there is a contravention of the upper limit of the isochronous period, and a cycle where an isochronous packet is missed appears.
On the other hand, if the bridge gives a one-cycle delay when the isochronous packet is transferred between buses, then as shown in FIG. 21B, the packet B can be transferred between buses for each cycle without depending on arbitration or a gap. That is to say, the packet B stored in the transmit buffer of the output portal in cycle C1 is transferred between buses in the interval of the isochronous gap from the point in time where the packet E is transmitted in cycle C2. Furthermore, the packet B stored in the transmit buffer of the output portal in cycle C2 is transferred between buses in the interval of the isochronous gap from the point in time where the cycle start packet is transmitted in cycle C3.
Next, referring to FIG. 22A and FIG. 22B is a description of the value of the isochronous delay which becomes necessary when the jitter attributable to traffic occurs in the cycle frequency. Here, as with the case of FIG. 21A and FIG. 21B, the portion shown by the half-tone dot mesh corresponds to the isochronous period. Furthermore, in FIG. 22A and FIG. 22B traffic other than that of packet B is omitted from the figure. Since at the input portal side bus and the output portal side bus, the traffic is mutually independent, then as shown in the figure, the cycle start packet is asynchronously transmitted to the other buses. In such a condition, the appearance for the case where a one cycle fixed delay is given by the bridge when the packet B is transferred between buses, is shown in FIG. 22A.
In the same figure, when the packet B in the cycle C2 of the input portal side bus is stored in the transmit buffer of the output portal, the output portal side bus has already entered cycle C3. Consequently, the packet B should be immediately transmitted to the output portal side bus. However the sub-action gap has already been detected at the output portal side bus, and this has entered the asynchronous period. Therefore, the packet B is transmitted to the output portal side bus in the next cycle C4, and in cycle C3 the packet B is missed.
In this way, if consideration is also given to jitter in the cycle frequency in addition to arbitration or gap, it is insufficient if the bridge only gives a delay of one cycle. That is to say, as shown in FIG. 22B, it is necessary to give a delay of at least two cycles in transmitting the packet transferred to the input portal side bus, to the output portal side bus. Here, a point of caution is that with the isochronous packet, since arbitration starts immediately after the cycle start packet, the isochronous delay must be counted based on the cycle of the output portal side bus.
Next, is a description concerning the transmit buffer amount which is necessary in order to give an isochronous delay of at least two cycles. The above-mentioned FIFO installed on a link layer LSI cancels jitter held by the input packet, by outputting packets at a constant period within a range which does not cause overflow or underflow. That is to say, in the case where FIFO is employed in the inter-bus transfer of the isochronous packets, since isochronous packets are stored in FIFO in a level which does not cause overflow or underflow, the packets are transmitted for each cycle to the output portal side bus. If the minimum two cycle requirement for the isochronous delay as mentioned before, and the presence of jitter of the cycle start packet are considered, then so that a cycle which misses a packet does not occur, transmission to the output portal side bus after packets of three or more cycles have been stored in the transmit buffer can be attempted.
Here, when the isochronous packet is transferred between buses using the above-mentioned transmit buffer control, the appearance of the transition of the transmit buffer amount is shown in FIG. 23. Here, the transmit buffer of the output portal is empty at the start time of the cycle C1. In this case, in cycles C1 to C3, concerning the storage of the packet from the input portal side bus to the transmit buffer, the accumulation amount of the transmit buffer also gradually increases. Then, after the packet C is stored in the transmit buffer, transmission to the output portal side bus is commenced. Here, since there is an influence of jitter held by the cycle start packet, the completion of the storage of the packet C to the transmit buffer is in the cycle C4 of the output portal side bus. Consequently, the packet A stored in the transmit buffer in cycle C1 is transmitted by cycle C5 rather than by cycle C4 so that the isochronous delay becomes four cycles. Moreover, as can be seen from the graph of transmit buffer accumulation amount shown in FIG. 23, since a packet exceeding the four cycle is stored in the transmit buffer, the capacity of the transmit buffer requires five cycle.
As described above, in the case where a conventional transmit buffer control is used, while ensuring an isochronous delay of two cycles or more, so that a cycle where a packet is missed is not generated at the output portal side bus, it is necessary to maintain a transmit buffer for five cycle. Here at S400 being the maximum transmission speed for the 1394 standard, isochronous packets of approximately 4 kilobytes can be transferred for each cycle. Consequently, in order to accumulate isochronous packets of five cycle, it is necessary to provide transmit buffers of approximately 20 kilobytes in each portal. This value of 20 kilobytes is an extremely large value when considering the current fabrication technology for link layer LSI""s, and the resultant cost increase due to the increase in chip size cannot be avoided. In spite of this, even if the size of the transmit buffer is reduced in order to keep down cost, since the buffer which can be used per one cycle is reduced, there is a problem in that this imposes a limit on the transfer throughput of the bridge.
Furthermore, when the conventional transmit buffer control is used, a problem such as shown in FIG. 24 also occurs. That is to say, in the cycle C4 of the input portal side bus, an isochronous packet which is to be transferred to the output portal side bus does not exist, and between the packet C and the packet D there is a space of one cycle. However, due to the effect of smoothing by the transmit buffer, at the output portal side bus, the space between the packet C and the packet D is shortened. That is to say, when the conventional transmit buffer control is used, when a cycle is present where an isochronous packet which is the object of inter-bus transfer is not transferred, the isochronous delay amount given to the packet before the cycle and after the cycle changes. Therefore, there is the problem of the occurrence of jitter in the output portal side bus.
The present invention takes into consideration the above-mentioned problems with the object of providing an isochronous packet transfer method which can give a constant isochronous delay to an isochronous packet to be transferred, even in the case where there is a transmit delay in the cycle start packet, and which can reduce the size of the transmit buffer which becomes necessary when isochronous packets are transferred between buses. Furthermore, it is a further object of the present invention to provide a recording medium on which is recorded an isochronous packet transfer control program for realizing such an isochronous packet transfer method, a bridge, and a packet transfer control LSI.
With a first aspect of the present invention, an isochronous packet transfer method for transferring an isochronous packet for which the transfer band has been secured in cycle units, between different buses, the method comprising the steps of: generating for each bus of an input side bus and an output side bus, cycle identification information which changes in synchronous with a timing for where a cycle start packet showing a start of the cycle is transmitted to a bus, respectively obtaining for the input side bus and the output side bus, elapsed cycle numbers from previously determined identical timings, based on the cycle identification information, and transmitting after a delay the isochronous packet input from the input side bus, to the output side bus, until a cycle number specified by delay information computed based on the elapsed cycle numbers, elapses on the output side bus.
Moreover, a second aspect of the present invention is an isochronous packet transfer method for transferring an isochronous packet for which the transfer band has been secured in cycle units, between different buses, the method comprising the steps of: respectively generating as input side cycle identification information and output side cycle identification information, cycle identification information which changes each time a cycle start packet showing a start of the cycle is respectively generated on an input side bus and an output side bus, acquiring the input side cycle identification information and the output side cycle identification information at a previously determined identical timing, and respectively generating input side reference cycle identification information and output side reference cycle identification information, and respectively computing a first value being an elapsed cycle number from a cycle showing the input side reference cycle identification information to a point in time where the isochronous packet appears on the input side bus, and a second value being an elapsed cycle number from a cycle showing the output side reference cycle identification information to a point in time where the isochronous packet is to be transmitted on the output side bus, generating delay information based on the first value and the second value, and transmitting the isochronous packet after a delay, to the output side bus until a cycle number indicating the delay information elapses on the output side bus.
With the first aspect and the second aspect, the buffer amount necessary for transferring the isochronous packets between buses can be reduced compared to heretofore. Furthermore, even under conditions where a transmit delay of the cycle start packet exists, a constant transfer delay is given to the isochronous packet.
Moreover, with a third aspect of the present invention, the respective procedures of the above-mentioned isochronous packet transfer are executed on a computer.
Furthermore, a fourth aspect of the present invention is a bridge which comprises: a switch circuit for performing packet switching among a plurality of buses which transfer at least isochronous packets for which the transfer band has been secured in cycle units, a plurality of cycle identification information generating circuits for generating cycle identification information which changes each time cycle start packets indicating a start of the cycle are generated on the buses, a plurality of reference cycle identification information generating circuits for acquiring the cycle identification information at previously determined identical timing and generating reference cycle identification information, a delay information generating circuit for generating delay information based on the cycle identification information and the reference cycle identification information, and a delay circuit for transmitting the isochronous packets for transfer between the buses after a delay, to the output side bus until a cycle number specified by the delay information on the output side bus elapses, wherein performs an operation as an input portal for outputting a packet received from the input side bus to the switch circuit, and an operation as an output portal for transmitting a packet output from switch circuit to an output side bus, and for transferring a packet including at least an isochronous packet between different buses.
As a result, the buffer amount necessary for transferring isochronous packets between buses, by the bridge can be reduced. Furthermore, even under conditions where a transmit delay of the cycle start packet exists, a constant transfer delay is given to the isochronous packet.
With a fifth aspect of the present invention, the respective circuits incorporated in the above-mentioned bridge are integrated to constitute a packet transfer control LSI.